home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19960715-19961006 / 000092_news@columbia.edu _Sun Jul 28 15:55:05 1996.msg < prev    next >
Internet Message Format  |  2020-01-01  |  7KB
  1. Return-Path: news@columbia.edu
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30]) by watsun.cc.columbia.edu (8.7.5/8.7.3) with ESMTP id PAA03544 for <kermit.misc@watsun.cc.columbia.edu>; Sun, 28 Jul 1996 15:55:04 -0400 (EDT)
  3. Received: (from news@localhost) by newsmaster.cc.columbia.edu (8.7.5/8.7.3) id PAA03849 for kermit.misc@watsun; Sun, 28 Jul 1996 15:55:03 -0400 (EDT)
  4. Newsgroups: comp.protocols.kermit.misc,comp.dcom.modems
  5. Path: news.columbia.edu!sol.ctr.columbia.edu!spool.mu.edu!agate!howland.reston.ans.net!cs.utexas.edu!news.sprintlink.net!news-stk-200.sprintlink.net!news.sprintlink.net!news-chi-13.sprintlink.net!news.sprintlink.net!news-chi-8.sprintlink.net!news2.noc.netcom.net!noc.netcom.net!netcomsv!uu3news.netcom.com!lia!glenn
  6. From: glenn@ia-us.com (Glenn Herteg)
  7. Subject: Re: Problem getting 28800 bps in C-Kermit 5A(190) on a v.34 internal
  8. Message-ID: <1996Jul28.193939.943@ia-us.com>
  9. Keywords: kermit, flow control
  10. Reply-To: glenn@lia.com (Glenn Herteg)
  11. Organization: IA Corporation, Emeryville, CA
  12. References: <CROTEN.96Jul24005129@crl.crl.com> <4t63nh$imc@samba.rahul.net> <CROTEN.96Jul27005455@crl.crl.com> <CROTEN.96Jul27022451@crl.crl.com>
  13. Date: Sun, 28 Jul 1996 19:39:39 GMT
  14. Lines: 96
  15. Xref: news.columbia.edu comp.protocols.kermit.misc:5664 comp.dcom.modems:145900
  16.  
  17. >>>: I _can_ set the speed to 38400 .. but max throughput indicates a solid 
  18. >>>: connection at _half_ that speed, 19200.  I _cannot_ seem to access 
  19. >>>[...]
  20. >>>: BTW, the system is an elderly Sun 386i, ...
  21.  
  22. Right there you've probably noted the real culprit.  A Sun 386i must be running
  23. an extremely old version of SunOS, and the tty drivers from those days are known
  24. to have broken flow-control.  I have the same problem in a Sun 3/80 running
  25. SunOS 4.1.1_U1; see below.
  26.  
  27. >I just tried to download a mail archive of uuencoded stuff with two versions 
  28. >of the above .kermrc file.  Archive size was 2280872 bytes.  
  29. >
  30. >_With_ 'set dial speed-matching off', I got the following:
  31. >1) _Lousy_ average packet sizes, all over the map but rarely at the 
  32. >   practical maximum of 8999 bytes.  
  33. >2) _Lousy_ throughput .. around 1200 CPS.  
  34. >3) Premature termination due to multiple timeouts less than a quarter of 
  35. >   the way through the download.  
  36. >
  37. >>Another problem I get from this combination of C-Kermit, terminal emulator, 
  38. >>and windowing system on my box is the (quite sudden) interruption of a file 
  39. >>transmission with the "too many NAKs" complaint from C-Kermit.  
  40. >>
  41. >>Owing to the fact that I am not _sure_ of binary file transmission accuracy ...
  42. >
  43. >In conclusion .. "set dial speed-matching off" makes things WORSE .. a LOT 
  44. >worse.  
  45.  
  46. What you describe are all symptoms of the same problem I'm seeing, which is
  47. that Kermit does not cope gracefully (ahem) with broken flow control.  I
  48. wouldn't mind so much, except that its attempted recovery can often result
  49. in a corrupted file getting transferred -- yep, the right number of bytes
  50. in the file at the receiving end, and kermit claims it's done, but a UNIX
  51. "sum" at both ends reveals the file didn't make it across intact.  And this
  52. is in spite of using Block Check 3 for checksumming packets!  I had somebody
  53. tell me the chances of this happening were 1 in {large number}; but sorry,
  54. folks, it happens in a macroscopic percentage of the time (half the time,
  55. perhaps?) on multi-megabyte files, under conditions I'll describe.
  56.  
  57. I have a Sun-3/80 running C-Kermit 5A(189), 30 June 93, SunOS 4.1 (BSD), with
  58. a 9600-baud Telebit QBlazer attached to serial port B.  On this serial line,
  59. I have installed a tap such that I can direct one side or the other of the
  60. conversation to an old dumb terminal.  By setting the terminal into "monitor"
  61. mode, I can see all the control characters going back and forth as well as
  62. the text -- a handy serial-line debugging tool.
  63.  
  64. Normally, I connect to the modem by setting the serial port to 19200 baud.
  65. This lets me take advantage of some buffering in the modem when I send stuff,
  66. and it generally works just fine.  I can download large files from my ISP
  67. just fine in this configuration, without error; the effective rate is choked
  68. by the 9600 baud modem connection, so that's all the 3/80 sees, and it can
  69. handle that rate just fine.  (I've tried a 19200 baud modem, and the poor
  70. 68030-with-two-wait-states in the 3/80 is overloaded at that speed, and must
  71. invoke flow control regularly to choke back the transfer rate.)
  72.  
  73. Sometimes I want to turn around and send out such a file to another site.  If
  74. I forget to think about it and just dial out using the same parameters, things
  75. will appear to work okay -- for awhile.  On the dumb terminal, though, I can
  76. see lots of CTRL-S and CTRL-Q characters being put out by the modem as it tries
  77. to cope with the overload of receiving data at 19200 and only being able to
  78. send at 9600.
  79.  
  80. The computer is pretty busy in this mode, so I'll often wander away, and come
  81. back to discover the perfmeter has dropped to zero load, and kermit isn't
  82. doing much.  If I recall correctly, a "Timeout" error is displayed in the
  83. fullscreen display.  If I allow this to go on, it may eventually recover and
  84. restart the transfer at full speed -- but that's generally after a period
  85. where it receives stuff and NAKs bunches of packets.  I've learned that if
  86. the transfer gets into this state but eventually completes, the received file
  87. *must* be checksummed for integrity outside of Kermit, because the Block
  88. Check 3 on the packet level was inadequate to ensure a reliable transfer.
  89.  
  90. This circumstance raises a design issue for future versions of Kermit.  There
  91. ought to be a way to perform a separate checksum algorithm over the entire
  92. file at each end of the transfer, and have these secondary checksums compared
  93. once the transfer is complete.  This ought to be automated as part of the
  94. protocol, if only under control of some new option.  Right now, I cannot
  95. trust any large transfer without checking manually.
  96.  
  97. If somebody (Frank?) is interested in the details, I suppose I could set
  98. up a transfer in some kind of debug mode and log all the activity, if that
  99. would help diagnose the problem.  (Obviously, the log files would be quite
  100. large.)  In particular, I'd like to know how the packet checksumming is
  101. fooled on such a regular basis.
  102.  
  103. The "fix" in my situation is to remember to use a different set of options
  104. to connect when I want to send files from the 3/80.  I end up having a
  105. separate line in my ~/.kdd file to set the computer port speed to 9600
  106. baud to match the modem's negotiated connection speed.  Under these
  107. conditions, there are far fewer CTRL-S and CTRL-Q characters exchanged,
  108. so the computer's broken flow-control is not driven into its failure mode.
  109.  
  110. Glenn Herteg
  111. glenn@ia-us.com
  112.